EP1221661 



Publication Title: 

Method and apparatus for dynamically updating a HTML based user interface 



Abstract: 

Abstract of EP 122 1661 

A metho 11a0 d and apparatus for dynamically updating a user interface are 
described. A data model is stored locally in a processing system. A presentation 
document is generated in the processing system based on the data model and a 
source document written in extensible markup language. The user interface is 
rendered in the processing system based on the presentation document. In 
response to an event, the processing system causes a corresponding change to 
the data model, and then automatically or semi-automatically determines a set of 
parts of the presentation document which are invalid as a result of the change 
and updates only those segments that are invalid. The user interface is then 
rendered based on the updated presentation document. 

Data supplied from the esp@cenet database - Worldwide 



Courtesy of http://v3.espacenet.com 



This Patent PDF Generated by Patent Fetcher(TM), a service of Stroke of Color, inc. 



(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 






(12) 



(H) EP 1 221 661 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

10.07.2002 Bulletin 2002/28 

(21) Application number: 02000007.1 

(22) Date of filing: 02.01 .2002 



(51) Int CI7: G06F 17/30 



(84) Designated Contracting States: 


(72) Inventor: Yarvin, Curtis G. 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Redwood City, CA 94063 (US) 


MC NL PTSETR 




Designated Extension States: 


(74) Representative: Jehle, Volker Armin et al 


AL LT LV MK RO SI 


Bosch, Graf von Stosch, Jehle, 




Patentanwalte, 


(30) Priority: 05.01.2001 US 755482 


Theatinerstrasse 8 




80333 Munchen (DE) 


(71) Applicant: Openwave Systems Inc. 




Redwood City, CA 94063 (US) 





(54) Method and apparatus lor dynamically updating a HTML based user interface 



(57) A method and apparatus for dynamically updat- 
ing a user interface are described. A data model is 
stored locally in a processing system. A presentation 
document is generated in the processing system based 
on the data model and a source document written in ex- 
tensible markup language. The user interface is ren- 
dered in the processing system based on the presenta- 



tion document. In response to an event, the processing 
system causes a corresponding change to the data 
model, and then automatically or semi-automatically de- 
termines a set of parts of the presentation document 
which are invalid as a result of the change and updates 
only those segments that are invalid. The user interface 
is then rendered based on the updated presentation 
document. 



CM 
< 

CO 
CO 

CM 
CM 



Event 



[ Data ]_ 



34 






Presentation 
Document 



FIG. 3 



Q_ 
LU 



Printed by Jouve, 75001 PARIS (FR) 



EP 1 221 661 A2 



Description 

FIELD OF THE INVENTION 

5 [0001] The present invention pertains to user interfaces for computer systems and other processing devices. More 
particularly, the present invention relates to a method and apparatus for dynamically updating a markup language 
based user interface. 

BACKGROUND OF THE INVENTION 

10 

[0002] Browsers are software applications used to access hyperlinked content, typically over a network. Common 
uses of browsers include viewing World Wide Web pages and using hyperlink-based applications (e.g., applications 
for booking travel reservations, on-line banking, trading stock, etc.) over the Internet. Hyperlinked content generally is 
written in a markup language, such as HyperText Markup Language (HTML), extensible Markup Language (XML), 
*5 Wireless Markup Language (WML) (for wireless devices), or variations of these languages. Browsers, therefore, are 
designed to interpret documents written in such markup languages and to display them to the user via a user interface 
(Ul). 

[0003] In a browser environment, a straightforward way to build an application Ul is to define the Ul in the browser's 
native markup language, such as extensible HTML (XHTML) or WML. However, when an application's state changes, 
20 the U I may need to change as well . Therefore, it is desirable to provide browsers with dynamic U Is for use with hyperlink 
based applications; that is, it is desirable to have Uls which change state in response to changes in state of the appli- 
cation. This problem has been solved, but not solved well. 

[0004] Conventional mechanisms for authoring dynamic Uls in browsers are much more complex than writing static 
markup pages. In the standard Document Object Model (DOM) approach, content authors make their documents dy- 

25 namic (using dynamic HTML, for example) by writing procedures which modify the documents in place, either as text 
or in an abstract structural representation. Besides making authoring difficult, the DOM approach undesirably breaks 
important abstraction boundaries in the browser. In particular, the DOM approach mixes the dynamic state of the ap- 
plication with its static definition, in a manner similar to self-modifying procedural code. DOM also makes no provision 
for automatic update of the presentation document (the document that is rendered and viewed by the user). That is, 

30 the presentation document can only be updated in response to a user-initiated request (e.g., an HTTP request). 

[0005] Another standard that could be used to implement dynamic Ul in browsers is extensible Stylesheet Language 
Transformation (XSLT). XSLT does cleanly separate the application data from the source document (which XSLT calls 
a "template" or "stylesheet") and the presentation document. However. XSLT requires the rendered application data 
to be in XML. This is problematic, because most applications store their dynamic data in the data structure primitives 

35 provided by the procedural language in which the application is written, allowing easy access to the data from the 
procedural code. Manipulating XML data is difficult, however. Furthermore, XSLT makes no provision for automatic or 
incremental update of the presentation document. That is, the presentation document can only be updated in response 
to a user-initiated request (e.g., an HTTP request), and it is not possible to update only the portions of the presentation 
document affected by a change in state. 

40 [0006] There are many server-side dynamic document engines in use today, a popular example of which is the 
ColdFusion Web application serverfrom Allaire Corporation of Newton, Massachusetts. By their nature, however, serv- 
er-side engines also are not incremental or automatic. The granularity of network update is too coarse, and there is 
no way for the server to force a page to update. 

45 SUMMARY OF THE INVENTION 

[0007] A method of dynamically updating a user interface in a processing system comprises generating a presenta- 
tion document, and responding to an event. The presentation document is generated based on a source document 
and a stored data set. The data set may be stored locally in the processing system. Responding to the event includes 
50 modifying the data set, determining whether the modification to the data set should affect the presentation document, 
and if the modification to the data set should affect the presentation document, then updating only the parts of the 
presentation document that correspond to the modification to the data set. The update may be performed automatically. 
[0008] Other features of the present invention will be apparent from the accompanying drawings and from the detailed 
description which follows. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] The present invention is illustrated by way of example and not limitation in the figures of the accompanying 
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drawings, in which like references indicate similar elements and in which: 

Figure 1 illustrates a network environment in which the present invention may be used; 

Figure 2 is a high-level block diagram of a processing system representing any of the processing systems shown 
5 in Figure 1 ; 

Figure 3 illustrates a technique for dynamic update of a presentation document; 

Figures 4A and 4B collectively form a flow diagram of the overall process of dynamically updating a user interface; 
Figures 5 and 6 illustrate two variation of a technique for automatically updating a presentation document; and 
Figure 7 illustrates a technique of semi-automatically updating a presentation document. 

10 

DETAILED DESCRIPTION 

[0010] A method and apparatus for dynamically updating a markup language based user interface are described. 
Note that in this description, references to "one embodiment" or "an embodiment" mean that the feature being referred 

*5 to is included in at least one embodiment of the present invention. Further, separate references to "one embodiment" 
in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually 
exclusive, unless so stated and except as will be readily apparent to those skilled in the art. Thus, the present invention 
can include any variety of combinations and/or integrations of the embodiments described herein. 
[0011] As described in greater detail below, the method and apparatus may be briefly characterized as follows. A 

20 data model is stored locally in a processing system, such as a conventional computer system or a hand-held computing/ 
communications device. A presentation document is generated in the processing system based on the data model and 
a source document written in extensible markup language (XML). The user interface is rendered in the processing 
system based on the presentation document. In response to an event, the processing system causes a corresponding 
change to the data model, and then automatically or semi-automatically determines the parts of the presentation doc- 

25 umentwhich are invalid as a result of the change. Such a partmay be, forexample, an individual XMLtag, aconsecutive 
sequence of tags, or essentially any other user interface feature. The processing system then updates only those parts 
of the presentation document that are invalid. The user interface is then rendered based on the updated presentation 
document. This process repeats each time an event is detected. 

[0012] Figure 1 illustrates a network environment in which the present invention may be used. Note, however, that 
30 the present invention does not have to be implemented in a network environment. As shown, a number of computer 
systems 1 are coupled to each other on an internetwork 2, which may be, for example, the Internet. One or more of 
the computer systems 1 may operate as a server to provide content to other computer systems on the internetwork 2 
(clients), such as Web pages and/or Web based applications. Hence one or more of the computer systems 1 may 
operate as clients of such servers. The clients may include one or more wireless devices 3, which are connected to 
35 the internetwork 2 through a wireless communications network 4 and one of the computer systems 1 that functions as 
a gateway server. 

[0013] Each of the computer systems 1 may be any of a variety of types of conventional processing systems, such 
as a conventional personal computer (PC) or workstation. The wireless device 3 may be any of a variety of types of 
hand-held, wireless communications and/or computing devices, such as a personal digital assistant (PDA), cellular 

40 telephone, two-way pager, or a conventional laptop (notebook) computer with a wireless modem. 

[0014] Figure 2 is a high-level block diagram of the hardware components of a processing system, which is repre- 
sentative of any of the processing systems shown in Figure 1 . Note that Figure 2 is conceptual in nature and is, therefore, 
not intended to portray any one specific architecture. It will be recognized that the specific architecture and the com- 
plements included therein can vary according to a number of factors, such as the role of the processing system (e.g.. 

45 client or server) and its specific intended functions. As shown, the processing system includes a processor 21 , read- 
only memory (ROM) 22, random access memory (RAM) 23, a mass storage device 24, a number (N) of input/output 
(I/O) devices 21-1 through 21 -N, and a communication device, all coupled to each other on a bus system 27. 
[0015] The bus system 27 may include one or more buses connected to each other through various bridges, con- 
trollers and/or adapters, such as are well-known in the art. For example, the bus system may include a "system bus" 

50 that is connected through an adapter to one or more expansion buses, such as a Peripheral Component Interconnect 
(PCI) bus. The I/O devices 25 may include devices such as a keyboard, a pointing device (e.g., mouse, touchpad, 
trackball, etc.), display device (e.g., CRT or LCD), etc. Mass storage device 24 may include any suitable device for 
storing large volumes of data in a non-volatile manner, such as a magnetic disk or tape, magneto-optical (MO) storage 
device, or any of various types of Digital Versatile Disk (DVD) or Compact Disk (CD) based storage. 

55 [0016] The communication device 26 may be any device suitable for or enabling the computer system 1 to commu- 
nicate data with a remote processing system over a data communication link, such as a conventional telephone modem, 
a wireless modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (DSL) modem, a 
cable modem, a satellite transceiver, cellular telephone transceiver, or the like. 
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[0017] The dynamic document updating techniques described herein may be implemented in software. More spe- 
cifically, the techniques may be implemented as part of a browser within a client processing system such as described 
above. Such an embodiment is henceforth assumed in this description, to facilitate explanation. The software embod- 
ying these techniques (e.g., the browser) may be contained within one or more storage devices within the processing 
5 system, such as RAM, ROM, a mass storage device, or combination thereof. Note, however, that in alternative em- 
bodiments, these techniques may be implemented at least partially in hardwired circuitry, or in a combination of hard- 
wired circuitry and software. 

[0018] Figure 3 illustrates a technique for dynamic update of a presentation document. A presentation document 31 
is generated and rendered so that it is viewable by user 32. The presentation document 31 is a function of a source 

10 document 33 and a data set 34. The data set 34 is stored in a dynamic memory element, such as a database or object 
system. The source document 33 is an XML document which is static and immutable, in the sense that it does not 
need to be modified dynamically to implement dynamic Ul using the mechanism described herein. The presentation 
document 31 is an XML document which defines a Ul (e.g., in XHTML). The function F(x) 35 is a reentrant, halting 
function. A simple example of the function F(x) is the expansion of "$" variable references to variable values in WML. 

*5 More complex functions may, for example, conditionally include tags or generate iterated tags from array values in the 
data space. Other types of functions F(x) are also possible. 

[0019] The data set 34 may be modified in response to an event, such as a user interaction (e.g., from a keyboard 
or mouse), a network interaction, or a timer expiration. In WML, XSLT, and other similar approaches, the path between 
the data set and the modifying function is passive; that is, updates of the presentation document are triggered by some 

20 external mechanism. For example, in ColdFusion and other server-side template models, update occurs in response 
to each HTTP request. Thus, updates are "manual", not automatic. XSLT specifies no update mechanism. 
[0020] In accordance with the present invention, the path between the data set 34 and the function F(x) is active. 
That is, changes in the data set 34 automatically (or semi-automatically) trigger updates of the presentation document 
31 . Thus, the active update mechanism can operate in either of two ways: automatic or semi-automatic. In the case 

25 of automatic update, changes to the data set 34 trigger updates of the presentation document 31 automatically. The 
presentation update may have a coarser grain than the data space changes. For example, if in processing a single 
event, n changes to the data set are made, there might only be one presentation update, which occurs after event 
processing completes. Automatic update is ideal for the author of the content. However, it is relatively more complex 
and difficult to implement efficiently than the semi-automatic update, as it requires a dependency graph which traces 

30 back through every component of the presentation function. 

[0021] In the case of semi-automatic update, the author defines dependency expressions which detect changes in 
the data set. In one embodiment, the dependency expression is associated with a tag in the source document. If the 
value of the dependency expression changes, the section of the presentation document generated by that tag is up- 
dated. To keep the presentation document up-to-date, all dependency expressionsthataffectthecurrentU I are checked 

35 after every event. For example, a dependency expression may be a checksum of an index of some data structure or 
a version number. Ideally, such a dependency expressions is fast to compute, and much faster to compute than the 
presentation function. The author is responsible for the performance of the application. 

[0022] Another aspect of the present invention is that the update can be incremental. That is, when the data set to 
changes, only the parts of the presentation document that depend on changed objects are updated. Incremental update 

40 is necessary for the semi-automatic case, and an optimization for the automatic case. Incremental update allows the 
dynamic document system to be used for fine-grained, low-latency operations, such as moving a scrollbar. 
[0023] A primary goal of a dynamic presentation document architecture is to serve as a declarative application model. 
It is widely recognized that declarative languages, such as HTML, make it easier to build application user interfaces 
than procedural (more precisely, Turing-equivalent) languages, such as Java or C++. However, interfaces built using 

45 conventional declarative application environments (i.e., browsers) are much less powerful than procedural environ- 
ments. Highly interactive applications with complex data models are difficult, impractical, or impossible to build. How- 
ever, using the techniques described herein, it is possible to design a declarative application model in which most 
interactive user interfaces are easy to build. 

[0024] The following elements are used to implement the automatic or semi-automatic, incremental dynamic update 
50 ofaUl: 

1) a presentation language, such as HTML, which can display all the textual and graphical primitives needed to 
render the application Ul; 

2) a simple, single-threaded event model, such as the DOM Level 2 event model for HTML (See Document Object 
55 Model (DOM) Level 2 Core Specification Version 1.0, W3C Recommendation November 13, 2000, World Wide 

Web Consortium), by which events can trigger side-effects; 

3) a powerful functional expression language, such as ECMAScript restricted to functional primitives, or Lisp; 

4) a local data storage mechanism, such as a store for ECMAScript objects; and 
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5) an extension to the presentation language to allow dynamic expressions to be embedded in and/or generate 
presentation markup. One such extension suitable for this purpose is described below. (Note that environments 
supporting style sheets must also support dynamic expressions in styles, which are not markup.) 

5 [0025] Regarding element "2)" above, note that a mechanism is needed to modify the application data storage in 
response to events. This mechanism can be a an imperative, procedural language, such as WML Script or Javascript, 
or in general, any mechanism for expressing side effects. 

[0026] Figures 4A and 4B collectively show the overall process of dynamically updating a user interface, according 
to one embodiment of the present invention. This process is performed (at least in part) by the application environment 

10 (e.g., the browser, as is henceforth assumed) as its event loop. Initially, in processing block 401 the browser waits for 
an event to occur. An event may be, for example, a user interaction, such as keyboard or mouse, a network interaction, 
or a timer expiration. When an event is detected in block 401 , then at block 402 the event is processed appropriately, 
depending on the type of event it is. An event binding is a procedural (Turing-equivalent) process that executes when 
the event occurs. It may modify transient storage (e.g., RAM) or persistent storage (e.g., hard disk or flash memory). 

15 Next, at block 403 the browser determines the set of parts of the presentation document that are invalid ("the invalid 
set") as a result of processing the event. The invalid set is initially empty. There are various ways of accomplishing this 
operation (block 403), which are described below, depending on whether the update mode is automatic or semi-auto- 
matic. 

[0027] Next, at block 404 the browser determines whether the invalid set is empty. If the invalid set is empty, the 
20 process loops back to block 401 . If the invalid set is not empty, then blocks 406 through 409 are performed for all 
elements contained in the invalid set. More specifically, at block 405 the browser initially selects one of the presentation 
document parts in the invalid set. At block 406, the browser identifies the corresponding segment in the source docu- 
ment, the evaluation of which caused the currently identified part of the presentation document to be invalid. 
[0028] The browser then determines at block 407 whether any other parts of the presentation document (i.e. , other 
25 than the currently identified part) are affected by the corresponding segment in the source document. For example, 
depending on the semantics of the presentation document, a single tag might affect the interpretation of other parts of 
the presentation document, which would usually (but not necessarily) adjoin the identified invalid part. As a more 
specific example, assuming the presentation language is HTML, then if the size of a table cell changes, the entire table 
may need to be laid out again. Another way to view this concept is that the presentation document has state that is 
30 functionally generated from it (e.g., the screen's frame buffer, and potentially other "intermediate" data structures, such 
as display lists) . An important part of the presentation process is propagating the incremental update of the presentation 
document to these structures while minimizing the loss of incrementality. 

[0029] Thus, if the result of the determination at block 407 is affirmative, then at block 413, the additional segments 
in the source document corresponding to these additional affected parts of the presentation document are identified. 
35 Following either block 407 or block 41 3, the browser 80 evaluates the source segment or segments identified in block 
406 and (if applicable) block 413 and replaces the invalid part or parts of the current presentation document with the 
result of the evaluation at blocks 408 and 409, respectively. If, at block 41 0, all elements in the invalid set have not yet 
been processed according to blocks 406 through 409, then the next element (part) 

in the invalid set is selected at block 41 4, and the process loops back to block 406. After all elements in the invalid set 
40 have been processed as described above, then at block 41 1 the browser passes the presentation document and a list 
of changed parts of the presentation document (resulting from processing the event) to the renderer. At block 412 the 
renderer redraws the screen to show the new presentation document, by redrawing only the changed parts of the 
presentation document. 

[0030] As described above, at block 403 the browser determines the invalid parts of the presentation document 
45 resulting from processing of the event. This operation involves determining whether any side effects which have oc- 
curred as a result of the event have modified the result of any expressions upon which the current Ul depends. Since 
this is an incremental update, the result of this phase is to construct the set of parts of the presentation document (e. 
g., individual XML tags or consecutive sequences of them) that executing the event binding has invalidated. 
[0031] There are at least four algorithms which may be used to implement block 403, as will now be described . The 
50 choice of algorithms depends on whether the update model is to be automatic or semi-automatic and on tradeoffs 
between performance and complexity. The first three algorithms relate to the automatic update mode; the fourth relates 
to the semi-automatic update mode. 

[0032] The first algorithm for automatic update is the simplest: the invalid set is always the whole presentation doc- 
ument. The second algorithm for automatic update is described now with reference to Figure 5. In this algorithm, the 
55 browser maintains a mark (pointer) 51 on every data object 52, referenced in expressions, which affects the current 
presentation document 53. The mark points to the set of parts 54 of the presentation document 53 which would be 
affected by modifying that object 52 (the "object invalid set"). During the processing of the event, every data object 
which the event procedure modifies is checked for this mark. If the mark is found, the invalid set is assigned the union 
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of itself and the object invalid set. This algorithm is referred to as "backward search". 

[0033] The third algorithm for automatic update is described now with reference to Figure 6. In this approach, the 
browser maintains, in a separate data structure 61 , the result of evaluating every expression in the source document 
which affects the current rendered semantics of the presentation document, either verbatim or as a checksum. For 

5 example, in Figure 6 each of expressions e and g corresponds to a set of parts 62e and 62g, respectively, of the 
presentation document 63. Results e c and g c in data structure 61 representthe current results of evaluating expressions 
e and g, respectively. For each expression, the result is paired with the set of parts of the presentation document which 
would be affected by a change in the value of the expression (the "object invalid set"). After event processing, the 
browser reevaluates every dynamic expression in the source document and compares the result, verbatim or as a 

10 checksum, to its saved value. If the value sale to match, the invalid set is assigned the union of itself and the object 
invalid set. This algorithm is referred to as "forward search". 

[0034] The fourth algorithm, which pertains to semiautomatic update, is described now with reference to Figure 7. 
In this approach, the browser maintains, in a separate data structure 71 , the result of evaluating every explicitly declared 
dependency expression in the source document which affects the current rendered semantics of the presentation 
*5 document, either verbatim or as a checksum. Such dependency expressions might be defined (by the author) for the 
purpose of, for example, providing faster update of the presentation document. 

[0035] As an example of this approach, consider a database of records, each of which has a unique identity. Assume 
it is desirable to display the list of these records by title. It is very likely to be faster to checksum the identities than the 
titles, and this is something only the author can know. Alternatively, the author could further attach a number to the 
20 database, which is incremented on every change and, thus, serves as a version number. The dependency expression 
is then trivial. 

[0036] In Figure 7 each of dependency expressions e 1 and g' corresponds to a set of parts 72e and 72g, respectively, 
of the presentation document 73. Results e' c and g' c in data structure 71 represent the current results of evaluating 
dependency expressions e 1 and g 1 , respectively. The result of the evaluation is paired with the set of parts 72 of the 
25 presentation document 73 that would be affected by a change in the value of the expression (the "object invalid set"). 
After event processing, the browser reevaluates every explicitly declared dependency expression in the source doc- 
ument and compares the result, verbatim or as a checksum, to its saved value. If they fail to match, the invalid set is 
assigned the union of itself and the object invalid set. 

[0037] As noted above, implementation of the dynamic update techniques described herein requires an extension 
30 to the presentation language to allow dynamic expressions to be embedded in and/orto generate presentation markup. 
An example of such an extension is now described, in the form of an XML transformation module referred to herein 
as "Wax". 

[0038] The Wax transformation module allows arbitrary XML applications to extend themselves to support dynamic 
content driven by a "Wax dictionary" (the data model), by hybridizing their native document types with the tags and 

35 attributes in the Wax transformation module. A Wax-enhanced XML document defines itself as a pure function of "Wax 
dictionary" state. Evaluating this function produces a static XML document in the native document type. The transfor- 
mation is purely functional (the original document is not modified) and stateless (declarative). Logically, a Wax-en- 
hanced application which displays a dynamic document updates itself continuously to remain consistent with changes 
in the Wax dictionary. In practice this may not always be trivial, but Wax is designed to facilitate practical incremental 

40 update. Validation is also a key concern. A design goal is to minimize the impact of Wax integration on the native 
document and application model. Combining the Wax transformation module with an arbitrary native Document Type 
Definition (DTD) or schema (such as WML or XHTML) is straightforward. The result can be validated with ordinary 
XML version 1 .0 tools. 

[0039] The Wax transformation module is a set of XML tags and attributes. Hybridizing a DTD with the transformation 
45 module involves adding the Wax attributes to each tag in the native DTD that may be transformed, and the Wax tags 
as content where they are appropriate. (The transformation module may also be used without manual hybridization, 
via the XML namespace mechanism. However, the explicit integration model may be preferable, as XML namespaces 
at present have no validation support. To clarify its nature as a module, tag and attribute names have the prefix, "wax:" 
in this description.) 

so [0040] Attribute integration starts with the version attribute, "wax:version". The simplest way to integrate "wax: ver- 
sion" is to add it to the root tag of the document type, and no other. The version attribute has three uses. First and 
most important, it declares that the text of all CDATA attributes (see attribute definition below) which are not Wax 
transformation attributes, on all tags which are children of the tag which declares "wax:version" (i.e., not including the 
version tag itself) must be processed as expressions in the Wax expression language. By default, attribute expressions 

55 are evaluated in scalar context; if the expression evaluates to nil, the attribute is elided. Wax transformation attributes, 
and any other attributes defined by the Wax markup modules (transformation and effect), are handled differently. Wax 
specifies whether each attribute is evaluated in scalar or vector context, and it elides all hybridized attributes before 
passing them to the native application. Second, the version attribute declares that all Wax transformation attributes on 
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tags which are children of the version tag, must be applied as specified by the document type. (Transformation attributes 
outside a version tag are errors and must be ignored.) Third, the version attribute declares the version of Wax for which 
the document is intended. If the major version number of the Wax processor differs from the major version number of 
the version attribute, the Wax processor must reject the document. 
5 [0041] The wax version attribute may be defined as follows (using XML document type definition syntax): 



waxtversion CDATA #IMPLIED 



[0042] The following is an example of the use of the version attribute in a source document: 



<html wax:version="Ll"> 



</html 

20 

[0043] The Wax transformation module also provides a set of transformation attributes. Transformation attributes 
dynamically elide or repeat tags. In general, transformation attributes can be integrated into the attribute set of any 
tag. All transformations may be legal for all tags, barring specific reasons to the contrary (for example, if it makes no 

25 sense to repeat a tag, it is reasonable to disallow "wax:foreach" on that tag) 

[0044] In one embodiment, Wax supports four simple transformation attributes: "wax:if", "wax:unless", "wax:foreach," 
and "wax:in". The wax:if and wax:unless attributes both evaluate their values as expressions in scalar context. If the 
expression evaluates to the string "false", wax:if elides its tag; if its value is "true", the tag is left intact. The wax:unless 
attribute has the opposite effect. If their values are anything other than "true" or "false", wax:if and wax:false leave their 

30 tags unchanged; however, in a development environment this should generate a warning or error. 
[0045] The attributes waxif and wax:unless may be defined as follows: 

wax:if CDATA #IMPLIED 

do 

wax:unless CDATA #IMPLIED 
40 [0046] The following is an example of the use of these attributes in a source document: 

<p wax:if="true">You should see this</p> 
45 <P wax:if="false">You should not see this</p> 

<p wax:unless="true">You should not see this</p> 
<p wax:unless= M false">You should see this</p> 

50 

[0047] The wax:foreach and wax:in attributes implement tag repetition. The wax:foreach attribute, which evaluates 
as a scalar, is an iteration variable name to apply to each list entry in wax: in, which evaluates as a vector. One copy 
of the tag is created for each entry in the list. References to the alias whose name is the iteration variable name are 
replaced with the corresponding iteration value for that entry. If either wax:foreach or wax:in is missing or nil, the tag 
55 is elided. 

[0048] The wax:foreach and wax: in attributes may be defined as follows: 
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wax:foreach CDATA #IMPLIED 
wax:in CDATA #IMPLIED 

[0049] The following is an example of the use of the wax:foreach and wax:in attributes in a source document: 
[0050] The expression 



<p wax:foreach= ,, i M wax:in= M (one, two)">Number {i}.</p> 

evaluates to 

15 

<p>Number one,</p> <p>Number two.</p> 

20 [0051] Although Wax does not define the processing model for the native application, it can use the author's knowl- 
edge of the document to help enable applications to implement more fine-grained update models. This is done via the 
"wax:depends" attribute, which lets the author specify a list of definitions on which a tag's dynamic content depends. 
(The same list might be extractable by some intelligent analysis of the tag and its contents, but this would both increase 
the burden on the Wax implementation, and define an environment in which the behavior of the system was dependent 

25 on a set of semantics which it would be difficult to define precisely, which is not what the author wants.) The value of 
wax:depends is a pattern: an expression which (unlike other attribute expressions) is not logically evaluated as the 
document is parsed, and must therefore be quoted as a literal. The pattern should evaluate to a list of names on which 
the tag may depend. Should the values of these names (or the contents of the list itself) change, the application will 
be notified, if it supports incremental update. 

30 [0052] The wax:depends attribute may be defined as follows: 



waxrdepends CDATA #IMPLIED 

35 

[0053] The following is an example of the use of the wax:depends attribute in a source document: 

<table wax:depends='"matrix.! m > 

40 

<tr wax:foreach=='*row H wax:m="[matrix,]* M > 

<td wax:foreach="ceir wax:in= M [matrix.{row)]. lf,, > 
45 <wax:text vaiue= ,l (>matrix.{row}.{cell}.value) t 7> 

</td> 

</tr> 

50 </table> 

[0054] The Wax transformation module contains two tags: <wax:text> and <wax:alias>. The <wax:text> tag substi- 
tutes a scalar Wax expression value directly into XM L #PCDATA (see definition below) It should be supported as content 
55 by any tag which already supports #PCDATA. 

[0055] The <wax:text> tag may be defined as follows: 
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<!FJ,EMENT wax-text F.MPTY> 
<!ATTLIST wax:text 

value CDATA #REQUIRED 

> 

10 [0056] The following is an example of the use of the <wax:text> tag in a source document: 

<p>Hello / <wax:text value= M world'7>*</p> 

15 

[0057] The <wax:alias> tag defines a Wax expression alias. The suggested integration model is for a document type 
to support <wax:alias> only as a direct child of the root tag. Done this way, aliases should apply to all expressions in 
the document. 

[0058] The <wax:alias> tag may be defined as follows: 



<!ELEMENT wax:alias EMPTY> 

<!All LIST wax:alias 

name CDATA #REQUIRED 

value CDATA #REQUIRED 

30 > 

[0059] The following is an example of the use of the <wax:alias> tag in a source document: 

35 <html wax:version= M l.r'> 

<wax:alias name^'planet" value= H world"/> 

40 <p>Hello, <wax;text value= ,, {planet}"/>.</p> 

</html> 

45 [0060] The following is an example of a simple application that can be constructed in accordance with the above 
teachings, to provide incremental, automatic and semi-automatic update of an application Ul. (The semi-automatic 
aspect is implemented using the wax:depends attribute.) The example is a working email application of the type which 
may be implemented in a wireless device, such as a cellulartelephone. This example is constructed using WML version 
1 .3 and the WAX transformation module. This example implements the simplest case of automatic update, i.e., inval- 

50 idation of the entire presentation document in response to a change in the data set. The application presents a list of 
the user's email messages, with actions such as reading and deleting available for each message. When the email 
store changes (for example, mail arrives in the background), the list will automatically update on the screen. 
[0061] The expression language and data store are a simple name-value pair model with queries based on lexical 
wildcards, such as the '*' commonly used in command-line shells. Note, however, that other languages, such as EC- 

55 MAScripts or Lisp, may be used as the expression language instead. 

[0062] The example below is annotated with explanatory remarks, which are indicated by the character "#" preceding 
the remark. Each remark precedes the code to which the remark refers. 
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<?xml version= f, l.(T?> 

<!DOCTYPE wrnl PUBLIC V/UNWIRED PLANET/ /DTD WML 1.1 / /EN" 
"http://www\uplanet com/DTD/ wml.xmT> 

# This tag indicates that this is a WML document that uses WAX. By a 
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# tag such as this, or external metadata (e.g., HTTP headers), 

# the browser can determine whether to apply WAX processing or to 

# simply use the source document as a static presentation document. 

# A version number implements forward / backward compatibility. 
# 

<wml wax:version= ,t 0.1"> 

# The following are alias statements in the WAX expression language 

# for convenience, like a C #define. 
# 

<alias name="app" value="app:/mair/> 
<alias name=' Inbox" value= M {app}.inbox"/> 
<alias name="session M value= M {app} .session" /> 

# The following aliases are actually defined in terms of dynamic 

# WAX expressions. For example, when we say "(empty}", it evaluates 

# as the alias directly below, which is a function that 

# returns "true" if there is anything in "app.inbox *", 

# "false" otherwise. 
# 

<alias name="empty ,r value= M (:empty {inbox}.*)V> 
<alias name="selection" vaiue=" {session} .selection" /> 
<alias name="current" value="{inbox}.(*{selection})"/> 

# The following is an alias that serves as a dependency expression 

# for the message list. That is, if a message is added or removed, 

# the value of this expression will change. 

# Here it is implemented with a checksum function. However, 

# one could also include a version number that the application must 

# manually change whenever it adds or deletes a message; this 

# would be more efficient and marginally more reliable, but 

# more work for the application author. 
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# 

<alias name= 'messages" value="(:checksum {inbox}.*)V> 

# The following is the main screen of the email application, with a list of 
messages. 

# 

# If any messages are added or deleted, just refresh the 

# whole card. (A more sophisticated implementation could choose 

# to redraw the result of the refresh with minimal screen 

# changes/ such as the way Microsoft Outlook animates downward when a 

# new message arrives.) 
# 

<card id= ,, main"> 
wax;depends="{messages}" 

> 

# If there are no messages, then so indicate. 
# 

<p wax:if=" (empty }">(No Messages)</p> 

# Otherwise, show a message list. 
# 

<p wax:unless= n {empty]" mode="nowrap"> 

# A standard WML menu. 
# 

<select name="selection"> 

# One <option> element (menu entry) for each message in the inbox 
# 

# If any field in the message changes (e.g., a message gets 

# read, and we have to change the icon), update the whole 

# message line (but not the other messages in the list). 
# 
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<option 

waxiforeach^Xmessage)" 

wax:in="[{inbox),]* H 
value= M {message]" 

> 

<img 

wax:if= tf ( :an y (*{inbox|. {message}. unread))" 
localsrc^littlecircleZ* 

/> 

<img 

wax:if='(:no (*{inbox}. {message). unread))" 
localsrc= l 'littlecirclel" 
/> 

<text 

value= " (*(inbox } . ( message J . title) 

, ( , (*{inbox}.{message}irom) , ) ,M 
/> 

</option> 
</select> 
</p> 

# Softkey bindings. Note that they change depending 

# message list, 
# 

<do label= M Read" 
type="accept M 
waxiunless^'lempty}" 
wax:depends="{messages} H 

> 

<go href="#read"> 

<store names" (selection) 1 ' value="$selection"/> 
</go> 
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</do> 

<do labei="CIear" 
type= M options M 
wax:uniess= n {empty}" 
wax:depends="{messages}" 

> 

<go href = ,f #clear M > 

<store name="{selection}" value="$selection"/> 
</go> 
</do> 

<do label= M Clear All" 
type="options" 
wax:tLaless=' , {empty}" 
wax:depends="{messages} M 

> 

<go href= M #clearall7> 
</do> 
</card> 

# Confirmation card for "clear all." The message database is 

# not expected to change while this is showing. (It is not 

# a problem if it does, however, no provision has been made for 

# updating the UI). 
# 

<card id= ,, clearall H > 
<p>Clear 
<text value="(:count (inbox}.*)V> 

message<text value=V wax:tinless= M (^q 1, (:count (inbox}.*))"/>? 
</p> 

<do type= ,, accept ,t label="Yes"> 
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<prev> 

<clearsetpattern= ,, {inbox}.'!"7> 
</prev> 
</do> 

<do type="cancer label="Cancer> 
<prev/> 
</do> 
</card> 

# Additional cards to improve WML/ WAX integration 
<card id="read"> 

<onevent type= M onenterforward"> 

<go href="(*{current}.href)"> 
<clear name=''{current}.unread"/> 

</go> 
</onevent> 

<onevent type="onenterbackward"> 
<prev/> 
</onevent> 
</card> 

<card id= M clear"> 
<onevent type== M onenterforward"> 
<prev> 

<clearset pattern= M {current}/* ,,, /> 
</prev> 
</onevent> 
</card> 

</wml> 



15 



EP 1 221 661 A2 



[0063] Thus, a method and apparatus for dynamically updating a markup language based user interface have been 
described. Although the present invention has been described with reference to specific exemplary embodiments, it 
will be evident that various modifications and changes may be made to these embodiments without departing from the 
broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to 
5 be regarded in an illustrative sense rather than a restrictive sense. 



Claims 

10 1. A method of dynamically updating a user interface in a processing system, the method comprising: 
storing a data set locally in the processing system; 

generating a presentation document based on a source document and the data set; and 

responding to an event by 
*5 modifying the data set in the processing system, 

determining whether the modification to the data set should affect the presentation document, and 
if the modification to the data set should affect the presentation document, then automatically updating 

only parts of the presentation document that correspond to the modification to the data set. 

20 2. A method as recited in claim 1 , wherein the processing system generates a user interface, and wherein the method 
further comprises using the updated presentation document to update the user interface dynamically. 

3. A method as recited in claim 1 , wherein the source document is written in an extensible markup language. 

25 4. A method as recited in claim 1 , wherein: 

the source document comprises a tag having a dependency expression as an attribute; 
said determining whether the modification to the data set should affect the presentation document comprises 
evaluating the dependency expression; and 
30 the method further comprises updating the presentation document, if appropriate, based on a result of the 

dependency expression. 

5. A method of dynamically updating a user interface on a local processing system, the method comprising: 

35 storing data in the local processing system; 

providing a presentation document in the local processing system based on the data and a source document 
written in an extensible markup language, wherein the presentation document is dependent upon one or more 
expressions that operate on the data; 

rendering the user interface in the local processing system based on the presentation document; 
40 detecting an event in the local processing system; 

responding to the event in the local processing system by 

causing a change to the data in the local processing system, 

determining whether the presentation document is dependent upon at least one expression, the result 
of which is affected by the change to the data, and 
45 if the presentation document is dependent upon at least one expression, the result of which is affected 

by the change to the data, then automatically updating only one or more parts of the presentation document 
that depend on said at least one expression, without updating the entire presentation document; and 
rendering the user interface in the local processing system based on the updated presentation document. 

50 6. A method as recited in claim 5, wherein: 

the source document comprises a tag having a dependency expression as an attribute; 
said determining comprises evaluating the dependency expression; and 

the method further comprises updating the presentation document, if appropriate, based on the dependency 
55 expression. 

7. A method and apparatus for dynamically updating a user interface in a processing system, the method comprising: 
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generating a presentation document in the processing system based on a stored data model and a source 
document written in extensible markup language; 

rendering the user interface in the processing system based on the presentation document; 

responding to an event in the local processing system by 
5 causing a change to the data set, 

determining a set of parts of the presentation document which are invalid as a result of the change, and 
automatically updating only those parts of the presentation document that are invalid, without updating 

the entire presentation document; and 

rendering the user interface based on the updated presentation document. 

10 

8. A method as recited in claim 7, wherein the data set is stored locally in the processing system. 

9. A method as recited in claim 7, wherein: 

*5 the source document comprises a tag having a dependency expression as an attribute; 

said determining a set of segments comprises evaluating the dependency expression; and 

the method further comprises updating the presentation document, if appropriate, based on a result of the 

dependency expression. 

20 10. A method of dynamically updating a user interface on a local processing system, the method comprising: 

generating a presentation document based on a source document and a stored data set; and 
responding to an event by 
modifying the data set, 

25 determining whether the modification to the data set should affect the presentation document, and 

if the modification to the data set should affect the presentation document, then automatically updating 
the presentation document based on the modification to the data set. 

11. A method as recited in claim 1 0, further comprising storing the data set locally within the local processing system. 

30 

12. A method as recited in claim 1 0, wherein: 

the source document comprises a tag having a dependency expression as an attribute; 
said determining whether the modification to the data set should affect the presentation document comprises 
35 evaluating the dependency expression; and 

the method further comprises updating the presentation document, if appropriate, based on the dependency 
expression. 

13. A method as recited in claim 10, wherein said automatically updating the presentation document comprises auto- 
40 matically updating only segments of the presentation document that correspond to the changed data, without 

updating the entire presentation document. 

14. A method as recited in claim 1 0, further comprising storing the data set locally within the local processing system, 
wherein said automatically updating the presentation document comprises automatically updating only segments 

45 of the presentation document that depend on the changed data, without updating the entire presentation document. 

15. A method as recited in claim 10, wherein the source document is an extensible markup language document. 

16. A method of dynamically updating a user interface on a local processing system, the method comprising: 

50 

providing a presentation document in the local processing system based on a source document written in an 
extensible markup language and a data set; 

rendering the user interface in the local processing system based on the presentation document; 
detecting an event in the local processing system; 
55 responding to the event in the local processing system by 

causing a change to the data in the local processing system, 

determining whether the presentation document is dependent upon the changed data, and 

if the presentation document is dependent upon the changed data, then automatically updating the pres- 
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entation document based on the change to the data; and 

rendering the user interface in the local processing system based on the updated presentation document. 

17. A method as recited in claim 1 6, further comprising storing the data set locally within the local processing system. 

18. A method as recited in claim 1 6, further comprising storing the data set locally within the local processing system, 
wherein said automatically updating the presentation document comprises automatically updating only one or more 
segments of the presentation documentthat depend on the changed data, without updating the entire presentation 
document. 

19. A method as recited ind claim 1 6, wherein: 



the source document comprises a tag having a dependency expression as an attribute; 
said determining whether the presentation document is dependent upon the changed data comprises evalu- 
*5 ating the dependency expression; and 

the method further comprises updating the presentation document, if appropriate, based on a result of the 
dependency expression. 

20. A method of dynamically updating a user interface on a local processing system, the method comprising: 

20 

generating a presentation document based on a source document and a stored data set; and 
responding to an event by 
modifying the data set, 

determining whether the modification to the data set should affect the presentation document, and 
25 if the modification to the data set should affect the presentation document, then updating only segments 

of the presentation document that correspond to the changed data, without updating the entire presentation 
document. 



21 . A method as recited in claim 20, further comprising storing the data set locally within the local processing system. 

30 

22. A method as recited in claim 20, wherein said updating comprises automatically updating only segments of the 
presentation document that depend on the changed data. 

23. A method as recited in claim 20, further comprising storing the data set locally within the local processing system, 
35 wherein said updating the presentation document comprises automatically updating only segments of the presen- 
tation document that depend on the changed data. 

24. A method as recited in claim 20, wherein the source document comprises a tag having a dependency expression 
as an attribute, and wherein said determining whether the modification to the data set should affect the presentation 

40 document comprises evaluating the dependency expression. 

25. A method as recited in claim 20, wherein the source document is an extensible markup language document. 

26. A method of dynamically updating a user interface on a local processing system, the method comprising: 

45 

providing a presentation document in the local processing system based on a source document written in an 
extensible markup language and a data set; 

rendering the user interface in the local processing system based on the presentation document; 
detecting an event in the local processing system; 
50 responding to the event in the local processing system by 

causing a change to the data set in the local processing system, 

determining whether the presentation document is dependent upon the data changed by the change to 
the data set, and 

if the presentation document is dependent upon the changed data, then updating only one or more 
55 segments of the presentation document that depend on said changed data, without updating the entire pres- 

entation document; and 

rendering the user interface in the local processing system based on the updated presentation document. 
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27. A method as recited in claim 26, wherein said updating comprises automatically updating said one or more seg- 
ments of the presentation document that depend on said changed data. 

28. A method as recited in claim 26, wherein the source document comprises a tag having a dependency expression 
5 as an attribute, and wherein said determining whether the presentation document is dependent upon the data 

changed by the change to the data set comprises evaluating the dependency expression. 

29. A method as recited in claim 26, further comprising storing the data set within the local processing system. 

10 30. A method as recited in claim 26, wherein said updating comprises automatically updating said one or more seg- 
ments of the presentation document that depend on said changed data; 

the method further comprising storing the data set within the local processing system. 
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31. A method of dynamically updating a user interface on a local processing system, the method comprising: 



storing, in the local processing system, a data set for use in generating a presentation document; 
generating a presentation document based on a source document and the stored data set; and 
responding to an event by 

modifying the data set in the local processing system, 
20 determining whether the modification to the data set should affect the presentation document, and 

if the modification to the data set should affect the presentation document, then updating the presentation 
document based on the modification to the data set. 

32. A method as recited in claim 31 , wherein said updating comprises automatically updating the presentation docu- 
25 ment. 

33. A method as recited in claim 31 , wherein the source document comprises a tag having a dependency expression 
as an attribute, and wherein said determining whether the modification to the data set should affect the presentation 
document comprises evaluating the dependency expression. 

30 

34. A method as recited in claim 31, wherein said updating comprises updating only segments of the presentation 
document that correspond to the changed data. 

35. A method as recited in claim 31 , wherein said updating comprises automatically updating only segments of the 
35 presentation document that depend on the changed data. 

36. A method as recited in claim 31 , wherein the source document is written in an extensible markup language. 

37. A method of dynamically updating a user interface on a local processing system, the method comprising: 

40 

storing data in the local processing system; 

providing a presentation document in the local processing system based on a source document written in an 
extensible markup language and the data; 

rendering the user interface in the local processing system based on the presentation document; 
45 detecting an event in the local processing system; 

responding to the event in the local processing system by 

causing a change to the data in the local processing system, 

determining whether the presentation document is dependent upon the changed data, and 
if the presentation document is dependent upon the changed data, then updating the presentation doc- 
50 ument based on the change to the data; and 

rendering the user interface in the local processing system based on the updated presentation document. 

38. A method as recited in claim 37, wherein said updating the presentation document comprises automatically up- 
dating the presentation document in response to the event. 



39. A method as recited in claim 37, wherein the source document comprises a tag having a dependency expression 
as an attribute, and wherein said determining whether the presentation document is dependent upon the changed 
data comprises evaluating the dependency expression. 
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40. A method as recited in claim 37, wherein said updating comprises updating only one or more segments of the 
presentation document that depend on the changed data, without updating the entire presentation document. 

41. A method as recited in claim 37, wherein said updating the presentation document comprises automatically up- 
5 dating only one or more segments of the presentation document that depend on the changed data, without updating 

the entire presentation document. 

42. A machine-readable storage medium containing instructions which, when executed by a machine, configure the 
machine to perform a method and apparatus for dynamically updating a user interface in a processing system, the 

10 method comprising: 

storing a data set locally in the processing system; 

generating a presentation document in the processing system based on the data model and a source document 
written in extensible markup language; 
*5 rendering the user interface in the processing system based on the presentation document; 

responding to an event in the local processing system by 
causing a change to the data set, 

determining a set of parts of the presentation document which are invalid as a result of the change, and 
automatically updating only those parts of the presentation document that are invalid, without updating 
20 the entire presentation document; and 

rendering the user interface based on the updated presentation document. 

43. A machine-readable storage medium as recited in claim 42, wherein: 

25 the source document comprises a tag having a dependency expression as an attribute; 

said determining a set of segments comprises evaluating the dependency expression; and 

the method further comprises updating the presentation document, if appropriate, based on a result of the 

dependency expression. 

30 44. a computing device comprising: 

a processor; 

an output device; 

a first storage unit containing a data set for use in generating an extensible markup language based presen- 
ts tation document; and 

a second storage unit containing instructions which configure the processor to 

generate the presentation document based on a source document written in an extensible markup lan- 
guage and the data set, wherein the presentation document is dependent upon one or more expressions that 
operate on the data; 

40 present a user interface at the output device based on the presentation document; 

detect an event; and 
respond to the event by 

causing a change to the data set, 

determine whether the presentation document is dependent upon at least one expression, the 
45 result of which is affected by the change to the data, and 

if the presentation document is dependent upon at least one expression, the result of which is 
affected by the change to the data, then automatically updating only one or more segments of the presentation 
documentthat depend on said at least one expression, without updating the entire presentation document, and 

present the user interface at the output device based on the updated presentation document. 

50 

45. A computing device as recited in claim 44, wherein the computing device is a wireless, hand-held computing device. 

46. A computing device as recited in claim 45, wherein the computing device is configured to receive the source 
document from a remote server over a network. 

55 

47. A computing device as recited in claim 44, wherein: 

the source document comprises a tag having a dependency expression as an attribute; and 
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the method further comprises updating the presentation document, if appropriate, based on the dependency 
expression. 
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